@Pay™Engine
The Best of Breed
Engine
A next
generation payment engine designed to route, switch and manage payment transactions on the
Internet, Intranets or Extranets, payor and/or payee accounts and back-office services.
Leverage Internet technologies to capture detailed transaction data and provide advanced
payment services to your customers.
@Pay™Engine is a
next generation payment engine designed to route, drive, switch, manage and authorize
payment transactions. This multi-tier, distributed application leverages powerful
databases and CORBA components to address the critical requirements of high volume
transaction operators for openness, reliability, performance, security, integrity,
scalability and redundancy. @Pay™Engine provides the foundation for the @dvanced
Payment™ Solution Suite. Specialized @Pay modules are added to @Pay™Engine to
build a specific solution. To seamlessly integrate these modules, @Pay™Engine uses a
set of three APIs: @Pay™Gate, @Pay™Channel and @Pay™Legacy.
@Pay™Engine can therefore interface with the various optional @dvanced Payment™
components, as well as custom-built application modules and existing systems to constitute
an advanced Internet payment solution.
Openness
@Pay™Engine is built on an open architecture allowing it to support all Internet
standards such as HTML, XML, Java, WAP, etc. Its three APIs ensure that @Pay™Engine
can support off-the-shelf components as well as other software standards.
Reliability
Reliability is the notion that a payment transaction message will not get lost en route.
@Pay™Engine is based on a transactional system which will not stop in an incoherent
state. Detailed logging information is provided in order to be able to recover from
external failure (such as Internet or card processing network failures).
Performance
@Pay™Engine ''s performance is assured by its ability
to run on high-end servers, its distributed and multi-thread architecture, and its support
for Persistence middleware. Based on customer statistics and functional requirements, both
pre-exploitation and on-site performance tuning can be achieved, mixing several fine
tuning mechanisms, including database distribution and tuning, distribution of processing
modules over several machines via CORBA, and data caching techniques using Persistence.
Security
@Pay™Engine uses
industry standards such as RSA SSL3, digital certificates, and PKI
authenticators to ensure that all parties in a transaction are authenticated
if and when needed. @Pay™Engine can also manage multiple application
authentication devices or methods and use off-the-shelf components
for advanced authentication devices such as hardware tokens, smartcards,
etc.
Integrity
Integrity is the
ability for a transaction to be broken down into unique events allowing
for in-depth examination. When @Pay™Engine receives a transaction,
it becomes an object, which is then stored by the platform. As the
transaction goes through its lifecycle, each event is recorded.
Since the transaction is seen as an aggregation of events, it can
be managed as a whole but also dissected into its smaller components.
Scalability
In the rapidly developing
e-commerce market, it is important to support a solution which can
grow as a business needs grow. @Pay™Engine is built on a distributed
CORBA architecture, allowing it to be run over multiple machines,
thereby distributing the workload. Instead of dedicating a single
hardware platform to running the entire application, several machines
may be used, each dedicated to a specific task or module. For example,
one CPU dedicated to the management of accounts; another dedicated
for transaction processing. @Pay™Engine can also be distributed
onto multiple platforms over the Internet to avoid network bottlenecks.
Redundancy
Use of CORBA allows transparent distribution of tasks over
several machines. This distribution mechanism allows operators to allocate several
machines to the same task, whereby other machines will transparently takeover operation in
case one fails or becomes unavailable.
![PayEngine.gif (40443 octets)](../gidmedia/images/@PayEngineW.gif)
@Pay Modules
Payor Account Manager
The Payor Account Manager manages payor account credentials, payment instruments, billing
and shipping addresses, administrative and marketing data, and technical data such as
authentication mechanisms used, etc.
Payee Account Manager
This module manages the payee’s acquiring contracts, policies associated with
supported payment brands, administrative and marketing data, etc.
Brand
Manager
The Brand Manager module manages operator brands. An operator can manage multiple brands
if so desired.
Transaction
Manager
The Transaction Manager
module coordinates the execution of payment transactions. It schedules
the transaction and maintains per transaction status.
Transaction
Registry
The Transaction Registry stores
transaction data and maintains the transaction status. Its business
logic includes a programmable state machine for tracking status
and checking operations.
Transaction
Log
The Transaction
Log registers all messages exchanged with the external Internet
world. Its main purpose is non-repudiation and idempotency implementation
within the Gateway.
Privilege
Manager
This module determines user authentication
schemes and operations access.
Registration
Interface
The Registration Interface allows operators to adapt payor registration
policy to their business requirements. The interface handles payor
registration and creation of payor accounts. The operator may decide
to add several sanity checks during the registration process. For
example: check payment instruments, check email address, ask consumer
to authenticate using an external authentication means (for instance
home banking).
Authentication
Interface
The Authentication Interface allows
for authentication of both parties (payee and payor) in a transaction.
Payment
Service Interface
The Payment Service Interface links
registered payment instruments to a per payment brand Service module.
This services module may be used for operations such as authentication
(e.g. debit card PIN), and delivery of transaction reports. Typically
the service module connects to external networks or other Legacy
networks.
Payment
Processor Interface
The Payment Processor Interface links the Transaction Manager to
a per acquiring contract external payment processing software. This
module executes basic payment operations such as transaction authorization
and capture. Typically this software connects to external payment
processing services such as credit card clearing facilities and
other Legacy systems.
Fraud
Detection Interface
The Fraud Detection Interface connects
to operator specific fraud detection policy software. The purpose
of this software is to recognize possible fraudulent operations,
such as usage of invalid credit card numbers, unusual spending patterns,
overspending, etc. For credit card payments, the ISO 8583 payment
processing module natively includes PAN number and black list checking.
Accounting
and Billing
Grants access to the payment registry.
Help
Desk Service
This module gives
the operator the ability to answer payor and payee questions pertaining
to their various accounts via web and email support.
Database
Development Tools
@Pay™Engine is based on an
Oracle database (v.7.3.4). Database development was handled using
Oracle tools such as Designer/2000 and Developer/2000.
Database
Administration Tools
Uses Database Management Systems Administration tools such as backup,
maintenance and replication.
Administration
Tools
The administration tools help manage
the @Pay™Engine platform. These tools are composed of different
interfaces from account management, to transaction management, to
payment actors.
APIs
@Pay™Gate
@Pay™Gate API is responsible for building online payment services. It allows external
Payment Gateways to connect to the @dvanced Payment™ platform. There are currently
two Payment Gateways supported (@Pay™SSL and @Pay™SET) with a third Gateway in
the demonstration stage (@Pay™SmartCard).
@Pay™Channel
@Pay™Channel API is responsible for all reporting and account administration
functions of payor and payee accounts. Payors can access a list of their payment
instruments, see a history of payment transactions by payment instrument, or check their
mailing address. Payees can also keep an eye on their accounts from viewing their
contracts with acquiring banks, to checking on the status of a transaction. Payors and
payees can also receive this information in a form compatible with a personal finance
manager such as Quicken or Microsoft Money.
@Pay™Legacy
@Pay™Legacy API connects the Internet world with the
existing Legacy world of banks and other such payment processors. Depending on the type of
payment, a payment transaction can be processed entirely on a Legacy payment platform in
the case of a credit card transaction, or on the @Pay™Engine platform as is the case
with a stored value transaction. This API is also responsible for foreign currency
exchange and fraud detection. Since it’s built on an open architecture, it can
accommodate third party off-the-shelf fraud detection programs.
Features and Benefits
Features |
Functions |
Benefits |
Open |
-Supports established and emerging standards. |
-Allows cost effective interoperability and universality. |
Modular |
-Integrates with existing legacy services.
-Allows deployment of advanced transaction services.
-Provides for customizable services. |
-Broadens services scope.
-Strengthens brand awareness.
-Allows cost effective integration with legacy services. |
Comprehensive |
-Enables universal payment instruments.
-Supports multicurrency. |
-Increases share of global financial transactions.
-Reaches out to foreign online communities. |
Distributed |
-Allows broad scalability. |
-Accommodates future growth. |
@Pay™Engine
Requirements:
- SUN Enterprise 450
- SUN Solaris 2.6 and above
- Oracle 7.3.4 and above
Back to top
The On Oracle logo is a trademark of Oracle
Corporation.
Home |
About Us | Products |
News | Partners |
Jobs | Events |
Contact Us | Site
Map
⌐ GlobeID Software - 1998
|